home *** CD-ROM | disk | FTP | other *** search
/ Freaks Macintosh Archive / Freaks Macintosh Archive.bin / Freaks Macintosh Archives / Textfiles / zines / Phrack / Phrack Issue 52.sit / Phrack52 / 52 / P52-15 < prev    next >
Text File  |  1998-01-26  |  13KB  |  291 lines
  1. ---[  Phrack Magazine   Volume 8, Issue 52 January 26, 1998, article 15 of 20
  2.  
  3.  
  4. -------------------------[  Technical Guide to Digital Certification
  5.  
  6.  
  7. --------[  Yggdrasil
  8.  
  9.  
  10.  
  11.  Introduction
  12.  ~~~~~~~~~~~~
  13.   Today's software technology provides not only flexible controls for web pages 
  14. and complex remote interaction (ActiveX controls, Java applets and Netscape 
  15. plugins) but also offers the possibility of downloading pieces of code for
  16. local execution to extend browsers capabilities.  A major issue being the
  17. fact that this code cannot be initially distinguished from malicious code 
  18. (virii/trojans, "man in the middle" attacks, forced downgrade, forgery of 
  19. electronic documents, etc), disguised as utilities.
  20.  
  21.   The point is that end users do not know who published of a piece of software,
  22. if the code has been tampered with, and what that software will do, (until they 
  23. download and execute it).  Anyone can create plugins, applets or controls 
  24. containing this potentially destructive code or even "intelligent" malevolent 
  25. code, able to communicate covertly with a remote server.
  26.  
  27.   Public-key cryptography has produced a number of different implementations
  28. to verify the authenticity of software, network objects, documents and data
  29. transactions (for example, Electronic Funds Transfer) using Digital IDs.
  30.  
  31.  
  32.  Authenticode Certifications
  33.  ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  34.   Microsoft recently adopted Authenticode technology to sign their ActiveX 
  35. based software.  Any individual or commercial software publisher desiring
  36. their code to be "trusted" must apply for and receive a Digital Certificate
  37. from an Authenticode Certificate Authority (CA), such as VeriSign.  The CA
  38. will request proof-of-identity, and other information, only then will they 
  39. verify the publishers credentials (even employing Dun & Bradstreet rating).
  40. After the CA has decided that the publisher meets its policy criteria, it 
  41. releases a Certificate (the expected cost is about $500 for a year, plus 
  42. additional costs for hardware storage for commercial developers, up to 
  43. $12,000).
  44.  
  45. [ God save the next-generation developers. ]
  46.  
  47.   A Digital Certificate contains the publishers public-key (and other info)
  48. encrypted according to the industry standard X.509 V3 certificate format and
  49. PKCS #7 signed data standards.
  50.  
  51.   The ITU-T recommendation for X.509 states that:
  52.  
  53. "It would be a serious breach of security if the CA issued a certificate for
  54.  a user with a public key that had been tampered with."
  55.  
  56.   All Certificates have an expiration time, but the CA may revoke them prior
  57. to that time if a publisher's private-key or CA's certificate is assumed to
  58. be compromised.  The CA may (or may NOT) inform the owner of the certificate.
  59.  
  60.  
  61.  Revocation Lists
  62.  ~~~~~~~~~~~~~~~~
  63.   The Revocation Lists, also called "black-lists", are held within entries as
  64. attributes of types CertificateRevocationList and AuthorityRevocationList.
  65.  
  66.   Their attribute types are defined as follows:
  67.  
  68. certificateRevocationList ATTRIBUTE ::= {
  69.   WITH SYNTAX CertificateList
  70.   EQUALITY MATCHING RULE certificateListExactMatch
  71.   ID id-at-certificateRevocationList }
  72.  
  73. authorityRevocationList ATTRIBUTE ::= {
  74.   WITH SYNTAX CertificateList
  75.   EQUALITY MATCHING RULE certificateListExactMatch
  76.   ID id-at-authorityRevocationList }
  77.  
  78. CertificateList ::= SIGNED { SEQUENCE {
  79.   version Version OPTIONAL,
  80.   signature AlgorithmIdentifier,                       <----+
  81.   issuer Name,                                              |
  82.   thisUpdate UTCTime,                                       |
  83.   nextUpdate UTCTime OPTIONAL,                          version 2
  84.   revokedCertificates SEQUENCE OF SEQUENCE {              only
  85.   userCertificate CertificateSerialNumber,             (extension)
  86.   revocationDate UTCTime,                                   |
  87.   crlEntryExtensions Extensions OPTIONAL } OPTIONAL,        |
  88.   crlExtensions [0] Extensions OPTIONAL }}             <----+
  89.  
  90.  
  91.  Implementation of X.509-3
  92.  ~~~~~~~~~~~~~~~~~~~~~~~~~
  93.   The ITU-T X.509 Directory Specification makes use of a set of cryptographic
  94. systems known as asymmetric Public-Key Crypto-Systems (PKCS).  This system
  95. involves the use of two keys (one secret and one public as used in common
  96. public key packages like PGP).
  97.  
  98.   Both keys can be used for encoding: the private key to decipher if the
  99. public key was used, and vice versa (Xp*Xs = Xs*Xp, where Xp/Xs are the
  100. key-encoding/decoding functions).
  101.  
  102.   When applied to Digital Signatures, the public key encryption is used to
  103. encipher the data to be signed after it's passed through a hash function.
  104. Information is signed by appending to it an enciphered summary of the info.
  105. The summary is produced by means of a one-way hash function, while the
  106. enciphering is carried out using the private key of the signer.
  107.  
  108.   For further information about X.509 and certificate types please read
  109. the ITU-T Recommendation X.509 ("The Directory: Authentication Framework").
  110.  
  111.  
  112.  Windows Trust API
  113.  ~~~~~~~~~~~~~~~~~
  114.   To ascertain an objects reliability under Win32, the WinVerifyTrust() API
  115. function is used, according to its prototype as follows:
  116.  
  117.   HRESULT                      ---------------  Description  ---------------
  118.   WINAPI
  119.   WinVerifyTrust (
  120.     HWND hwnd,                 <>0 to allow user to assist in trust decision
  121.     DWORD dwTrustProvider,     0 = provider unknown, 1 = software publisher
  122.     DWORD dwActionID,          specifies what to verify
  123.     LPVOID ActionData          information required by the trust provider
  124.   )
  125.  
  126.   The HRESULT return code will be TRUST_E_SUBJECT_NOT_TRUSTED if the object
  127. is not trusted (according to the specified action in dwActionID).  An error
  128. code more detailed than this could be provided by the trust provider.
  129.  
  130.  
  131.  Creation of a Digitally Signed message
  132.  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  133.   PKCS #7 specifies several "types", such as ContentInfo, SignedData and
  134. SignerInfo.  Version 1.5 of PKCS #7 describes the ContentInfo type as:
  135.  
  136. ContentInfo ::= SEQUENCE {
  137.   contentType ContentType,
  138.   content
  139.     [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
  140.  
  141. ContentType ::= OBJECT IDENTIFIER
  142.  
  143. the content is (or better: MAY be) an octet-stream ASCII string to be passed
  144. to the selected digest algorithm (an example is MD2, see RFC-1321).
  145.  
  146. The first step is to encode the ContentInfo field according to PKCS #7.
  147. This is the resulting encoded data:
  148.  
  149. == DATA BLOCK #1 ==
  150.  
  151. {30 28} 06 09                               0x0609: contentType = data
  152. 2A 86 48 86 F7 0D 01 07 01                  PKCS #7 data-object ID
  153. A0 1B                                       [0] EXPLICIT
  154.    04 [msg_len]                             content = OCTET STRING
  155.       [octet stream representing
  156.        the ASCII string, msg_len bytes long]          <-- value (*)
  157.  
  158. This (*) data is the input stream to the encoding algorithm (MD2 or other):
  159.  
  160. (the identifier of the PKCS #7 data object is {1 2 840 113549 1 7 1})
  161.  
  162. == DATA BLOCK #2 ==
  163.  
  164. {30 20} 30 0C                               0x300C: digestAlgorithm
  165. 06 08 2A 86 48 86 F7 0D 02 02               algorithm ID = MD2
  166. 05 00                                       parameters = NULL (0x00)
  167.    04 [block_len]                           digest
  168.       [encoded data (MD2 output)]
  169.  
  170. (the object identifier of the MD2 algorithm is {1 2 840 113549 2 2})
  171.  
  172. This data is the encoded DigestInfo.  It will be encrypted under RSA using
  173. the user's private key.
  174.  
  175. According to PKCS #1, RSA encryption has two main steps: an encryption data
  176. block is constructed from a padding string and the prefixed message digest;
  177. then the encryption block is exponentiated with the user's private key.
  178.  
  179. The encryption block EB is the following 64-octet string:
  180.  
  181. 00 01                                       block type
  182. FF FF FF FF FF FF FF FF FF FF FF FF FF FF   padding string
  183. FF FF FF FF FF FF FF FF FF FF FF FF FF
  184. 00                                          separator (0x00)
  185. [here goes the whole DATA BLOCK #2]         data bytes (prf. message digest)
  186.  
  187. Now we need to encode various information: a SignedData value from the inner
  188. ContentInfo value, then the encrypted message digest, the issuer and serial
  189. number of the user's certificate, the certificate data, the message digest
  190. algorithm ID (MD2) and the encryption algorithm ID (PKCS #1 RSA).
  191.  
  192. The encoded SignedData is:
  193.  
  194. == DATA BLOCK #3 ==
  195.  
  196. 30 82 02 3D
  197. 02 01 01                                    version = 1
  198. 31 [size of inner data block]               digestAlgorithms
  199.    30 [size]
  200.       06 08 2A 86 48 86 F7 0D 02 02         algorithm ID = MD2
  201.       05 00                                 parameters = NULL (0x00)
  202.    [ContentInfo data]                       content = inner ContentInfo
  203. A0 82 01 [size]                             certificates
  204.    [certificate data]                       user's certificate
  205. 31 81 [size]                                signerInfos
  206.    30 81 [size]
  207.    02 01 01                                 version = 1
  208.       30 [size]                             issuerAndSerialNumber
  209.          [issuer data]                      issuer
  210.          02 04 {12 34 56 78}                size (4), serialNumber (12345678)
  211.       30 [alg_size]                         digestAlgorithm
  212.          06 08 2A 86 48 86 F7 0D 02 02      algorithm ID = MD2
  213.          05 00                              parameters = NULL (0x00)
  214.       30 [dig_size]                         digestEncryptionAlgorithm
  215.          06 [sz]                            rsaEncryption (d.E.A.)
  216.             2A 86 48 86 F7 0D 01 01 01
  217.          05 00                              parameters = NULL (0x00)
  218.       04 [data_size]                        encryptedDigest
  219.          [encrypted digestInfo encoded data block]
  220.  
  221. Finally, a ContentInfo value from this SignedData data block is encoded (once
  222. again, using PKCS #7):
  223.  
  224. 30 82 02 [size]
  225.    06 09 2A 86 48 86 F7 0D 01 07 02         contentType = signedData
  226.    A0 82 02 [size]                          [0] EXPLICIT
  227.       [here goes the whole DATA BLOCK #3]   content = SignedData value
  228.  
  229. (the object identifier of PKCS #7 signedData is {1 2 840 113549 1 7 2})
  230.  
  231.  
  232.  PKCS Key Example
  233.  ~~~~~~~~~~~~~~~~
  234.   The following is the full hex dump of the above PKCS #7 encoded key.
  235.  
  236.  
  237. HEX Dump -------------------------------------:   ASCII Dump ----:
  238.  
  239. 30 82 02 50 06 09 2A 86 48 86 F7 0D 01 07 02 A0   0..P..*.H.......
  240. 82 02 41 30 82 02 3D 02 01 01 31 0E 30 0C 06 08   ..A0..=...1.0...
  241. 2A 86 48 86 F7 0D 02 02 05 00 30 28 06 09 2A 86   *.H.......0(..*.
  242. 48 86 F7 0D 01 07 01 A0 1B 04 19 41 20 64 65 6D   H..........A dem
  243. 6F 20 43 6F 6E 74 65 6E 74 49 6E 66 6F 20 73 74   o ContentInfo st
  244. 72 69 6E 67 A0 82 01 5E 30 82 01 5A 30 82 01 04   ring...^0..Z0...
  245. 02 04 14 00 00 29 30 0D 06 09 2A 86 48 86 F7 0D   .....)0...*.H...
  246. 01 01 02 05 00 30 2C 31 0B 30 09 06 03 55 04 06   .....0,1.0...U..
  247. 13 02 55 53 31 1D 30 1B 06 03 55 04 0A 13 14 45   ..US1.0...U....E
  248. 78 61 6D 70 6C 65 20 4F 72 67 61 6E 69 7A 61 74   xample Organizat
  249. 69 6F 6E 30 1E 17 0D 39 32 30 39 30 39 32 32 31   ion0...920909221
  250. 38 30 36 5A 17 0D 39 34 30 39 30 39 32 32 31 38   806Z..9409092218
  251. 30 35 5A 30 42 31 0B 30 09 06 03 55 04 06 13 02   05Z0B1.0...U....
  252. 55 53 31 1D 30 1B 06 03 55 04 0A 13 14 45 78 61   US1.0...U....Exa
  253. 6D 70 6C 65 20 4F 72 67 61 6E 69 7A 61 74 69 6F   mple Organizatio
  254. 6E 31 14 30 12 06 03 55 04 03 13 0B 41 20 64 65   n1.0...U....A de
  255. 6D 6F 20 55 73 65 72 30 5B 30 0D 06 09 2A 86 48   mo User0[0...*.H
  256. 86 F7 0D 01 01 01 05 00 03 4A 00 30 47 02 40 0A   .........J.0G.@.
  257. 66 79 1D C6 98 81 68 DE 7A B7 74 19 BB 7F B0 C0   fy....h.z.t.....
  258. 01 C6 27 10 27 00 75 14 29 42 E1 9A 8D 8C 51 D0   ..'.'.u.)B....Q.
  259. 53 B3 E3 78 2A 1D E5 DC 5A F4 EB E9 94 68 17 01   S..x*...Z....h..
  260. 14 A1 DF E6 7C DC 9A 9A F5 5D 65 56 20 BB AB 02   ....|....]eV ...
  261. 03 01 00 01 30 0D 06 09 2A 86 48 86 F7 0D 01 01   ....0...*.H.....
  262. 02 05 00 03 41 00 45 1A A1 E1 AA 77 20 4A 5F CD   ....A.E....w J_.
  263. F5 76 06 9D 02 F7 32 C2 6F 36 7B 0D 57 8A 6E 64   .v....2.o6{.W.nd
  264. F3 9A 91 1F 47 95 DF 09 94 34 05 11 A0 D1 DF 4A   ....G....4.....J
  265. 20 B2 6A 77 4C CA EF 75 FC 69 2E 54 C2 A1 93 7C    .jwL..u.i.T...|
  266. 07 11 26 9D 9B 16 31 81 9B 30 81 98 02 01 01 30   ..&...1..0.....0
  267. 34 30 2C 31 0B 30 09 06 03 55 04 06 13 02 55 53   40,1.0...U....US
  268. 31 1D 30 1B 06 03 55 04 0A 13 14 45 78 61 6D 70   1.0...U....Examp
  269. 6C 65 20 4F 72 67 61 6E 69 7A 61 74 69 6F 6E 02   le Organization.
  270. 04 14 00 00 29 30 0C 06 08 2A 86 48 86 F7 0D 02   ....)0...*.H....
  271. 02 05 00 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01   ...0...*.H......
  272. 05 00 04 40 05 FA 6A 81 2F C7 DF 8B F4 F2 54 25   ...@..j./.....T%
  273. 09 E0 3E 84 6E 11 B9 C6 20 BE 20 09 EF B4 40 EF   ..>.n... . ...@.
  274. BC C6 69 21 69 94 AC 04 F3 41 B5 7D 05 20 2D 42   ..i!i....A.}. -B
  275. 8F B2 A2 7B 5C 77 DF D9 B1 5B FC 3D 55 93 53 50   ...{\w...[.=U.SP
  276. 34 10 C1 E1 E1                                    4....
  277.  
  278.   Many other demo (not only ;) keys, tons of related C++ source/libraries for
  279. Linux and Win32 and documentation can be found on my web site at this address
  280. (case sensitive):
  281.  
  282.   http://members.tripod.com/~xception_0x0A28/penumbra.html
  283.  
  284.  
  285.                  "That which does not kill us
  286.                   makes us stronger"
  287.                                      -- Friedrich Nietzsche
  288.  
  289. ----[  EOF
  290.  
  291.